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IANA Registry for Interactive Connectivity Establishment (ICE) Options 


Abstract 


It has been identified that "Interactive Connectivity Establishment 
(ICE): A Protocol for Network Address Translator (NAT) Traversal for 
Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE 
options. This document defines this missing IANA registry and 
updates RFC 5245. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6336. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


"Interactive Connectivity Establishment (ICE): A Protocol for Network 
Address Translator (NAT) Traversal for Offer/Answer Protocols" 
[RFC5245] defines a concept of ICE options. However, the ICE RFC 
fails to create an IANA registry for ICE options. As one ICE option 
is under specification in [ECN-FOR-RTP], there is now a need to 
create the registry. 


RFC 5245 says: "ICE provides for extensibility by allowing an offer 
or answer to contain a series of tokens that identify the ICE 
extensions used by that agent. If an agent supports an ICE 
extension, it MUST include the token defined for that extension in 
the ice-options attribute". 


Thus, as future extensions are defined, these ICE options need to be 
registered with IANA to ensure non-conflicting identification. The 
ICE option identifiers are used in signalling between the ICE 
endpoints to negotiate extension support. RFC 5245 defines one 
method of signalling these ICE options, using the Session Description 
Protocol (SDP) with Offer/Answer [RFC3264]. 


This document updates the ICE specification [RFC5245] to define the 
"Interactive Connectivity Establishment (ICE) Options" registry. 


2. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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IANA Considerations 
This document defines a registry "Interactive Connectivity 
Establishment (ICE) Options" for ICE options that can be used in the 
SDP "ice-options" attribute or other signalling parameters carrying 
the ICE options. 
1. ICE Options 
An ICE option identifier MUST fulfill the ABNF [RFC5234] syntax for 
"ice-option-tag" as specified in [RFC5245]. This syntax is 
reproduced here for simplicity, but the authoritative definition is 


in the ICE RFC: 


ice-option-tag = 1*ice-char 
ice-char = ALPHA / DIGIT / "+" / "/" 


ICE options are of unlimited length according to the syntax; however, 
they are RECOMMENDED to be no longer than 20 characters. This is to 
reduce message sizes and allow for efficient parsing. 

Registration of an ICE option in the "Interactive Connectivity 
Establishment (ICE) Options" registry is done using the Specification 
Required policy as defined in "Guidelines for Writing an IANA 
Considerations Section in RFCs" [RFC5226]. 

A registration request MUST include the following information: 

o The ICE option identifier to be registered 

o Name, Email, and Address of a contact person for the registration 
o Organization or individuals having the change control 


o Short description of the ICE extension to which the option relates 


o Reference(s) to the specification defining the ICE option and the 
related extensions 


This document registers no ICE option. 
Security Considerations 


As this document defines an IANA registry for an already existing 
concept, there are no new security considerations. 
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